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In  this  paper  we  consider  a  resource  allocation  problem  which  is  local 
in  the  sense  that  the  number  of  users  competing  for  a  particular  resource  at 
any  time  instant  is  bounded  and  also  at  any  time  instant  the  number  of 
resources  that  a  user  is  willing  to  get  is  bounded.  The  problem  may  be 
viewed  as  distributedly  achieving  matchings  in  dynamically  changing  hyper^ 
graphs.  We  show  that  this  problem  is  related  to  the  fundamental  problem  of 
handshake  communication  (this  problem  can  be  viewed  as  achieving  matchings  in 
dynamically  changing  graphs,  via  distributed  algorithms)  in  that  an  efficient 
solution  to  each  of  them  implies  an  efficient  solution  to  the  other.  We 
provide  real-time  solutions  to  the  resource  allocation  problem  (i.e., 
distributed  algorithms  with  real  time  response)  via  probabilistic  techniques. 
No  probability  assumptions  about  the  system  behavior  are  made,  but  processes 
are  allowed  the  ability  to  make  independent  probabilistic  choices.  One  of 
our  solutions  assumes  the  existence  of  an  underlying  efficient  handshake 
communication  system.  Anothe  is  based  on  basic  synchronization  primitives 
(flag  variables).  The  special  case  of  equi-speed  processes  is  examined. 
Applications  are  drawn  to  dining  philosophers,  scheduling  and  two-phase 
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ABSTRACT 


In  this  paper  we  consider  ^  resource  allocation  problem  which  is  local 
in  the  sense  that  the  number  of  users  con^eting  for  a  particular  resource  at 
any  time  instant  is  bounded  and  also  at  any  time  instant  the  number  of 
resources  that  a  user  is  willing  to  get  is  bounded.  The  problem  may  be 
viewed  as  distributedly  achieving  matchings  in  dynamicalty  changing  hyper^ 
graphs.  We  show  that  this  problem  is  related  to  the  fundamental  problem  of 
handshake  cormunioation  (this  problem  can  be  viewed  as  achieving  Inatchings  in 
dynoinically  changing  graphs ^  via  distributed  algorithms),  in  that  an  efficient 
solution  to  each  of  them  implies  an  efficient  solution  to  the  other.  We 
provide  real-time  solutions  to  the  resource  allocation  problem  (i.e., 
distributed  algorithms  with  real  time  response)  via  probabilistic  techniques. 
No  probability  assumptions  about  the  system  behavior  are  made,  but  processes 
are  allowed  the  ability  to  make  independent  probabilistic  choices.  One  of 
our  solutions  assumes  the  existence  of  an  underlying  efficient  handshake 
communication  system.  Another  is  based  on  basic  synchronization  primitives 
(flag  variables) .  The  special  case  of  equi-speed  processes  is  examined. 
Applications  are  drawn  to  dining  philosophers,  scheduling  and  two-phase 
locking  in  databases.  " 


y 
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1. 


INTRODUCTION 


1.1  The  Resource  Granting  System 

In  this  paper  we  consider  a  resource  allocation  problem  which  is 
local  in  the  sense  described  in  [Lynch,  1980].  The  set  of  resources  p 
and  the  set  of  user  processes  U  may  be  infinite  sets.  However,  there 
is  a  limit  to  the  number  of  user  processes  requesting  a  particular  resource. 
Resources  are  controlled  by  a  set  of  granting  processes  R.  Each  granting 
process  jCR  controls  a  resource  p(j)  €p*  We  assume  user  processes 
communicate  only  with  those  gremting  processes  for  which  they  request 
resources.  (It  is  easy  to  superimpose  each  granting  process  into  a 
requesting  user  process  so  that  U  =  R) . 

A  system  described  as  above,  is  called  a  Resource  Granting  System 
(V(Z^)  ,  Tbp  of  ^  i  fn  Hynamioallv  r'bang'irtn 

for  resource  allocation.  This  is  done  in  a  distributed  way,  by  only  a 

local  communication  between  granting  and  requesting  processes.  An  imple¬ 
mentation  of  the  RGS  determines  the  programs  that  the  processes  run. 

It  is  called  symmetric  if  the  programs  do  not  depend  on  the  location 
of  the  processes  in  the  network.  At  each  time  t^O  the  actions  of  the 
requesting  user  processes  U  are  specified  by  an  adverse  oracle  , 

(which  may  be  an  "enemy”  of  the  resource  allocation  algorithm,  by  setting 
actions  in  the  worst  way  to  increase  the  response  time.)  tj/  also  has  the 
capability  to  select  at  time  t  =  0  the  schedule  of  the  speeds  of  all 
processes  at  all  times  t>0.  The  oracle  ^  is  restricted,  to  allow 
users  to  keep  asking  for  their  resources  for  at  least  some  nonzero  length 
time  interval.  We  assume  that  there  is  a  global  time  t  totally  ordering 
events,  but  processes  do  not  have  access  to  it.  An  RGS  with  priorities 
is  defined  to  be  a  resource  granting  system  in  whicli  the  requesting  processes 
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caoununicate  to  each  resource  granting  process  a  rational  number  on  the  interval 
[0,1],  indicating  the  priority  of  the  request*  These  priorities  can  change 
dynamically,  however  they  are  assumed  to  preserve  their  value  for  at  least  a 
fixed  constant  number  of  process  steps.  The  processes  of  R  use  these 
assigned  priorities  to  grant  their  controlled  resource  with  preference  to 
users  of  higher  priority.  This  must  be  done  in  a  way  avoiding  user  starvation - 

1.2  Complexity  of  an  RGS 

In  the  sequel  we  consider  a  process  to  be  tame  during  a  time  interval 

if  it  is  speed  bounded  by  fixed  constants  during  that  interval.  We  do  not 

assume  processes  always  tame,  however  they  are  supposed  to  be  tame  in  the 

complexity  analysis  of  response  time.  We  require  that,  at  no  time,  any 

granting  process  i€R  simultaneously  grant  the  resource  R(i)  to  more  than 

one  requesting  process .  We  also  require  that ,  as  soon  as  a  process  j  €  u 

has  got  all  its  required  resources,  then  it  can  keep  them  only  for  a  bounded 

length  time  interval  (resulting  in  a  bounded  niomber  of  its  steps,  if  the 

process  is  tame).  Let  resources (i)  be  the  set  of  all  possible  resources 

that  a  process  i€u  is  going  to  ever  request,  and  let  resources^(i)  be 

the  set  of  resources  i  is  requesting  at  time  instant  t.  Let  k.  .  be 

1 ,  t 

I resources^ (i) |.  For  each  time  t,  the  willingness  digraph  is  defined 

such  that  if  i €  U  and  j  €  R  .  and  if  i  requests  (or  has  been  granted) 
resource  p(j)  at  t,  then  the  edge  i  ^  ^  belongs  to  G^.  Let  also  j  “J  ^ 
if  the  granting  process  j  is  willing  to  allocate  (or  has  granted)  its 
resource  to  user  i.  Let  v^  be  the  mcucimxam  valence  of  the  nodes  j  of  G^ 
such  that  j  €  R,  at  time  t.  In  the  following  we  will  assume  that  v^  and 
k.  are  above  bounded  by  constants  v,k  at  any  time  t  and  that  v^k. 

This  does  not  imply  anything  about  the  sets  resources (i)  ViGu,  which 
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could  be  unbounded.  We  also  assume,  as  in  [Lynch,  1980],  that  each  resource 
allocator  j€R  has  a  set  available  to  it  of  size  ^v,  containing  the 

names  of  those  processes  willing  to  get  the  resource.  We  assume  this  to  be 
a  primitive  of  our  system  (which  could  be  implemented  by  a  queued  message 
system  or  by  other  means) .  Finally,  we  restrict  any  oracle  so  that  as 
soon  as  it  produces  a  request  for  a  resource  (i.e.,  it  orders  the  appearance 
of  the  edge  ^  ^  3  in  for  i€u,  j  G  R)  it  has  to  insist  on  that  request 

for  at  least  a  bounded  time  interval.  Note  that  the  relation  ^  Ceui  be 
viewed  as  a  time  varying  hypergraph  with  node  set  11  =  U  U  R  and  edge  set 
E  =  {{i}  U  resource^{i) ,  i€u}.  An  RGS  implementation  dynamically  achieves 
matchings  in  this  hypergraph.  We  allow  probabilistic  RGS  implementations 
where  processes  can  use  independent  random  number  generators. 

Fix  an  RGS  implementation  which  may  be  probabilistic.  In  the  following 
we  assume  processes  to  be  tame  over  the  stated  time  intervals.  For  each  k 
(O^k^v)  and  oracle  let  the  Vi~grant  response  be  the  random  variable 

Yk  ^  giving  the  length  of  the  interval  A  required  for  any  process  i G  U 
to  have  k  resource  requests  simultaneously  granted,  given  that  i  requested 
these  resources  during  the  entire  interval  A,  with  priority  1.  Let  the  mean 
k-grant  response  be  y.  Tciax{mean{y  over  all  oracles  .  For  each  e 

in  [0,1]  let  the  z-error  k-grant  response  be  the  minimiim  such  that 

for  every  oracle 

Prob{Yj^  >  l-e  . 

The  RGS  implementation  is  real  time  if  for  every  kG{l,...,v}  and  for  every 
cG  (0,1],  Yj^(c)  and  independent  of  any  global  measure  of  the  network 
(except  v)  .  The  network  here  has  as  nodes  the  elements  of  11  and  its  edges 
{u,r}  mean  that  p(r)  G  resources (u) .  Note  that  if  the  RGS  implementation  is 
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real  time,  then  is  constant,  independent  of  any  global  measure  of  the 

graph  H  of  the  network  (except  v)  • 

1. 3  Previous  Work 

(Lynch,  1980]  considered  the  problem  of  fast  allocation  of  resources  in 
a  distributed  system.  Her  RGS  implementation  was  a  deterministic,  non- 
symmetric  one  (processes  were  allowed  to  know  the  color  of  each  resource  in  a 
coloration  of  the  resource  graph)  and  the  communication  system  adopted  was  a 
message  system  requiring  buffered  communication.  The  k-grant  response  was  of 

X  (h  ) 

the  order  x(H) -v  -T  where  x(H)  is  the  chromatic  number  of  the  resource 
graph  and  T  is  the  time  required  for  process  communication.  Note  that  since 
resources (i)  for  i€U  may  be  unbounded,  in  the  worst  case  x(H)  can  be  as 
large  as  the  number  of  processes  |ll|, 

1.4  Results  of  this  Paper 

We  shall  present  in  Section  3  a  probabilistic  implementation  of  an  RGS 
which  has  mean  k-grant  response  Yj^  =  0(kv  *T*log  v)  and  e-error  k-grant  response 

Y^<€)  .  o(kv’‘lo9(i)  T  (^)) 

where  T  and  T (c)  are  the  mean  time  and  e-error  time  required  for  handshake 
communication  between  processes  (see  Appendix  I  for  definitions) .  In  [Reif , 
Spirakis  1981],  [Reif,  Spirakis  1982]  handshake  communication  implementations 
were  given  with  T  =  o(v^)  and  T(e)=o(v^log  (1/e)).  Note  that  these  imple- 
mentations  achieve  real  time,  thus  the  resulting  RGS  implementation  is  also 
real  time  with 

(l)  'O’ 


0(kt 


k  2 


log  v)  and  y^U) 


>(k^^^^og 
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However,  any  other  handshake  communication  implementation  would  also  do. 

In  Section  4  we  present  a  basic  way  to  implement  a  real  t^me  RGS  in  both 

cases  of  synchronous  and  asynchronous  processes.  The  implementation  is 

probabilistic.  No  underlying  handshake  communication  system  is  assumed. 

Instead,  the  means  of  synchronization  between  processes  in  U  and  R  are 

flag  variables  (which  are  written  by  just  one  process  and  allowed  to  be  read 

-  k+1 

by  at  most  one  other  process).  The  response  time  has  mean  =  0(kv  ) 
k+1 

and  =  0(kv  log(l/e)). 


Organization  of  Paper 


This  paper  is  organized  as  follows;  Section  2  contains  applications  of 
RGS  to  dining  philosophers,  scheduling,  two-phase  locking  in  databases,  and 
real-time  handshake  communications.  Section  3  discusses  a  real  time  RGS 
assuming  an  underlying  real  time  handshake  communication  system.  Section  4 
discusses  a  real  time  RGS  implementation  by  use  of  low  level  synchronization 
primitives  (i.e.  boolean  and  rational  flags) .  Section  4  first  discusses  an 
implementation  in  which  processes  have  the  same  speeds  but  their  actions  are 
relatively  shifted  in  time.  At  the  end  of  Section  4  we  generalize  our  algo¬ 
rithms  to  the  case  where  processes  are  tame.  The  Appendix  defines  handshake 
communication  systems  and  their  performance  measures. 


2.  APPLICATIONS 

2.1  Hasty  Dining  Philisophers 

As  a  simple  example,  we  consider  an  interesting  RGS  system  which  we  call 

*^ha6ty  dining  philosophers**.  Let  the  requesting  processes  U  be  distinct 

integers,  r_,...,r  _,  and  the  granting  processes  R  be  0,..,,n-l  so  that 

0  n- 1 

unR:5  0.  The  resources  arc  rrA*;:  {p  (0)  , . . .  ,p  (n-1)  }  .  Each  philosopher 
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r.€u  has  resources (r . )  consisting  of  the  forks  {p(r.),  ,  )}. 

j  j  j  (3+i)moa  n 

Thus,  the  resource  graph  H  is  a  cycle  of  length  n.  The  "hasty  dining 

philosophers"  has  a  high  level  real  time  RGS  implementation  with  mean  2-grant 

2 

response  Y2=0(l)  and  e-error  2-grant  response  =0(log(l/e)  ). 

The  low  level  RGS  implementation  gives  ^2^^^  =  O  (log  (1/e) )  . 

Intuitively,  the  RGS  implementation  requires  each  philosopher  r^  to  be  at 
any  time  granted  both  forks  of  resource (r^)  in  expected  constant  time,  but 
r^  must  be  "hasty"  and  relinquish  these  resources  within  constant  time  inter¬ 
val.  Note  that  for  each  i E {o, . . , ,n-l}  the  granting  process  i  can  be 
placed  within  process  r^ ,  thus  resulting  in  essentially  only  n  processes. 

2 . 2  Scheduling 

Suppose  an  acyclic  digraph  D  is  given  with  node  out-degree  ^k  and 
in-degree  ^v.  This  graph  can  be  separated  into  levels.  We  assume  processes 
residing  in  the  nodes  of  D  can  operate  only  after  getting  all  their  Tesources 
(which  reside  at  the  nodes  which  have  no  successors) .  Each  process  operates 
just  once  and  then  becomes  a  resource  granting  process,  to  serve  the  next 
higher  level.  All  its  successors  are  deleted.  So,  each  node  is  initially  a 
requesting  process  and  after  it  gets  all  its  resources  once,  it  becomes  a 
resource  granting  process.  By  assuming  a  real  time  RGS  implementation  the 
above  system  can  be  processed  in  time  of  the  order  of  the  depth  of  the  digraph. 

2.3  Two  Phase  Locking  in  Databases 

Two-phase  locking  is  a  concurrency  control  method  in  databases  (see  for 
example  (Bernstein,  Goodman  1980])  with  the  feature  that  as  soon  as  a  trans¬ 
action  releases  a  lock,  it  never  obtains  additional  ones.  The  technique  of 
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two-phase  locking  produces  serializable  transaction  executions.  We  propose 
here  a  way  to  implement  two-phase  locking  in  a  distributed  database /  which 
is  different  from  any  known  algorithms-  The  underlying  assumption  is  that 
transactions  are  allowed  to  act  on  the  data  only  if  they  got  all  the  locks. 

Let  the  processes  of  the  user  set  U  be  called  tvccncaction  modutes  and  the 
processes  of  set  R  be  called  data  tnoduLes^  If  each  trcmsaction 
requests  to  lock  at  most  k  data  modules  at  a  time  and  if  at  most  v  trans¬ 
actions  can  compete  for  a  lock  at  a  time  instant  t,  then  a  real  time  RGS 
will  result  in  real  time  lock  allocation  per  transaction.  The  transaction 
modules  go  through  a  "round"  (of  constauit  n\xmber  of  steps  in  duration)  during 
which  they  communicate  with  all  data  modules  they  want  to  lock.  They  keep 
the  locks  they  get  only  for  constant  number  of  steps  hoping  in  the  meanwhile 
to  get  all  of  them.  If  the  round  finishes  and  they  did  not  succeed  in 
getting  all  the  locks,  then  they  release  whatever  they  got  and  try  again  in 
the  next  round.  Given  the  previously  stated  response  time  ^  real¬ 

time  RGS,  one  can  now  decompose  the  distributed  system  into  a  system  of 
parallel  servers  with  qeometricallv  distributed  service  time,  (one  per  trans¬ 
action  module) .  It  is  straichtforward  then  to  analyze  the  transaction  waiting 
time,  throughput  etc.,  bv  assuming  a  probability  distribution  in  the  trans¬ 
action  arrival  rate. 

2.4  Handshake  Communication  in  Real  Time  Via  a  Real  Time  RGS 

We  can  implement  here  handshake  communication  in  the  sense  of  the 
Appendix,  assuming  the  existence  of  a  real-time  RGS.  Assume  that  each  of  the 
processes  j  €  R  control  just  one  resource  called  the  channeZ  and  when  they 
allocate  this  resource,  we  say  they  open  the  channel.  Each  of  the  processes 
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iCU  have  |resource^(i)  |  ^  1,  so  as  soon  as  any  process  i€u  is  granted 
one  resource,  process  i  does  not  compete  for  any  other,  until  i  releases 
that  resource.  The  processes  i€U  are  assumed  to  open  their  channel  when 
they  are  granted  their  resource  and  to  close  their  channel  when  the  resource 
is  removed.  Given  bounds  v  on  the  processes  i  €  U  competing  for  the  same 
P(j)#  and  a  bound  k^v  on  the  nxamber  of  resources  a  user  is  willing 

to  be  granted  at  any  time  t  ,  a  real-time  RGS  will  imply  a  real-time  hand¬ 
shake  corrmunioation  scheduler,  with  the  same  time  performance  (see  Appendix  I) . 
It  is  interesting  to  note  (as  we  show  in  Section  3)  that  one  can  implement  also 
a  real  time  RGS  by  a  real  time  distributed  communication  subsystem. 


3.  HIGH  LEVEL  RGS  IMPLEMENTATION  ASSUMING  A  REAL-TIME  HANDSHAKE 
COMMUNICATION  SYSTEM 

3.1  The  Algorithm 

We  shall  assume  here  the  existence  of  a  DCS  [as  in  Appendix  I] .  Then, 
the  implementation  of  a  probabilistic  real  time  RGS  is  as  follows: 

The  granting  processes  i  are  always  willing  to  communicate  only  to  the 
requesting  processes  of  the  set  S^  (as  defined  in  the  introduction) .  The 
requesting  processes  are  willing  to  communicate  only  to  those  granting 
processes  whose  resources  they  want  (or  have  been  allocated) .  By  communication 
here  we  mean  a  handshake  communication. 

The  granting  processes  do  forever  the  following  grant  algorithm  which  is 


a  loop,  a  single  execution  of  which  is  called  a  grant-phase •. 
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Grant  Algorithm 
for  process  i  €  R 


Do  forever 
begin 


[1]  .  Do  a  handsheike  communication  with  anyone  of  the  requesting 

processes  in  and  get  their  priorities. 

[2] .  Probabilistically  select  jCS^.  (The  values  of  the  priorities 

determine  the  probability  of  each  requesting  process  to  be 
selected  as  determined  in  Section  3.2.) 

[3] .  On  first  handshaJce  with  the  selected  process  j,  say  **yes"  to  j 

allocating  your  resource  to  j . 

[4] .  For  2.S  steps,  the  granting  process  says  *'no"  to  any  requesting 

process  but  j  in  any  handshake  and  says  "yes”  to  j  on  any 
communication. 

(Here  s  contains  at  least  time  T(e)  and  it  must  be  exactly 

equal  to  t(g)  in  duration,  if  i  goes  as  fast  as  it  can.  Assume 

that,  for  tame  processes,  the  duration  of  a  step  is  between  two 

nonzero  values,  6  .  ,  6  .  Then  s  =  T(e)/6  .  .) 

min  max  min 

[5] .  On  handshake  with  any  other  process  them  j,  the  granting  process 

i  says  "no" .  On  first  handshake  communication  with  j ,  the 
granting  process  i  says  "no"  to  j ,  indicating  tJiat  resource 
p(i)  has  been  withdrawn  from  j  and  ending  the  grant  phase. 

[6] .  Wait  for  w  steps  randomly  chosen  from  (0,6s]. 
end 


The  requesting  processes  continuously  attempt  to  communicate  with  the 
resources  they  want  to  be  granted. 

We  may  view  the  actions  of  the  requesting  processes  time-sliced  in  i[*ounds 
each  round  being  the  minimal  time  interval  in  which  i  communicates  at  least 
once  with  all  k  of  the  resource  controlling  processes  of  the  resources 
which  i  wishes  to  obtain. 
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3.2  Probabilistic  Selection 

We  give  here  a  very  simple  implementation  of  probabilistic  selection 
of  one  out  of  ^v  processes  (using  their  priorities)  in  0(v)  steps  as 
required  in  phase  2  of  the  algorithm  in  Section  3.1.  This  implementation 
can  easily  be  improved  to  0(log  v)  steps  (see  [Reif,  Spirakis  1982J). 

Suppose  that  each  resource  allocator  i  has  just  a  random  number 
generator  drawing  uniform  numbers  between  0  and  1.  Let  p. ^ /P. • »P. 
be  the  priorities  of  the  processes  requesting  the  resource  of  i  at  the 
current  time . 

To  implement  the  selection  process  we  do  the  following: 

[2.1] .  draw  a  random  number  r  in  [0,1]. 

[2.2] .  find  the  process  name  x  for  which 


x-1 

2  p 

k=l 


ik 


v 

k=l  ^ 


<  r  < 


X 

I  p 

k=l 


ik 


v 

^  ^ik 
k«l 


Note  that  stage  [2.1]  takes  one  step  and  stage  [2.2]  takes  0{v)  steps  since 
we  have  to  evaluate  2  partial  sums  each  time  and  test.  The  current  partial 
sums  can  be  evaluated  from  previous  partial  sums  by  a  single  addition. 


3.3  Analysis 

We  now  probabilistically  analyze  the  algorithm  of  Section  3.1.  By  the 
stated  properties  of  DCS, 

Prob{a  round  length  is  <T(e)}  ^  (1-e)^ 


It  is  easy  to  see  that 
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LEMMA  3.1.  The  average  length  in  steps  of  a  grant  phase  is  <  12  s. 

Proof .  The  stages  1,  3  and  5  of  the  algorithm  will  take  s  steps  each 
by  properties  of  DCS.  Stage  2  takes  steps  ^  s  =  0(v)  for  known  implementations 
of  DCS.  Stage  3  is  guaranteed  to  have  2s  steps.  Stage  6  takes  ^6s  steps. 
From  now  on  we  will  assume  (for  simplicity)  that  all  priorities  are  equal  to  1. 
Let  X  be  the. event  "a  requesting  processes  gets  a  "yes”  answer  (in  a  hand¬ 
shake  in  stage  3)".  We  have: 

Prob{x} 

=  Prob{it  actually  competes  for  the  resource} 

Prob{it  gets  a  "yes"  given  it  actually  competes} 

^  -  .  -  - 

12  V 


Note  that  the  length  of  the  granting  phase  of  each  resource  allocator  is  chosen 
in  such  a  way  to  allow  a  requesting  process  to  have  all  the  resources  for  at 
least  one  of  its  steps,  given  that  it  gets  all  of  them  in  a  round. 

If  we  consider  a  subclass  of  oracles  9^  which  put  maximxim  contention 
on  the  system,  then  these  oracles  will  give  the  worst  case  of  the  response 
time.  However,  in  this  case 

Prob{x}  <  “  ,  for  oracles  ^£9^  , 


Let  u  be  the  random  variable  giving  the  number  of  rounds  required  for 
process  i  to  succeed  in  being  granted  all  k  resources  in  one  round.  Then 


prob(„..)  <  (l  -  ’  (i)‘ 


implying 


mcan(u)  <  (12  v) 
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Y,^(e)  =  log(i) 

and 

-  lc+9 

Yj^  =  0(kv^^^  log  V) 

4.  REAL  TIME  RGS  IMPLEMENTATION  BY  USE  OF  FLAG  VARIABLES 

4.1  The  Algorithm  for  the  Case  of  Synchronous  Processes 

For  simplicity,  we  shall  temporarily  assume  here  that  all  processes  go 
by  the  same  speed.  (Section  4.3  drops  the  assumption  of  synchronous  processes) 
However,  we  also  allow  for  this  case  that  for  some  time  in  the  past  this  did 
not  happen  (the  processes  were  asynchronous)  and  so,  at  t>0  the  execution 
ot  tneir  programs  in  rime  may  oe  snirtea  iin  an  aaverse  way;  relative  to  each 
other . 

The  communication  between  granting  and  requesting  processes  is  done  here 
by  flag  variables.  To  read  one  flag  requires  one  of  the  process  steps.  In 
case  of  priorities,  some  of  the  flags  are  allowed  to  have  rational  values 
between  0  and  1.  The  flags  P^^  indicate  the  priority  of  user  j  with 
respect  to  resource  i.  In  the  simple  case  of  equal  priorities  all  flags 
are  boolean.  Each  granting  process  i  has  for  each  requesting  process  j  a 
special  flag  F^^  whose  value  indicates  if  the  resource  p{i)  is  allocated 
to  j.  If  j  reads  F^^  and  finds  it  0,  then  it  understands  that  it  lost 
the  resource.  The  granting  processes  execute  forever  the  following  loop, 
called  a  grant  phase  •. 
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Grant  Algorithm 
of  Granting  Process  i £  R 


Do  forever 
begin 

[1] .  Rea^  the  priority  flags  of  the  requesting  processes  in  the  set  S^. 

[2] .  Probabilistically  select  each  of  the  requesting  processes  j€S. 

according  to  their  priorities  (see  Section  3.2). 

[3] .  Set  the  flag  ^ij  to  1  indicating  that  resource  p(i)  has  been 

allocated  to  process  j. 

[4] .  Sleep  for  cv  steps  (i.e.,  do  cv  no-ops). 

[5]  .  Set  the  warning  flag  j  to  indicate  to  j  that  he  will  loose 

resource  after  at  most  2cv  steps.  Wait  2cv  steps. 

[6]  .  Set  j  to  0  (remove  resource) .  Erase  the  warning  by  setting 

L. .  to  0. 

[71.  Wait  for  w  steps  where  w  is  a  random  integer  selected  uniformly 
from  t0,5cv]. 

end 


Note:  Stages  1,2  each  take  0(v)  steps.  The  algorithm  requires  them  to  each 
take  cv  steps.  This  constant  c  is  here  a  fixed  constant,  used  in  stages  4, 
5,6. 

Each  user  process  j€U  executes  continously  the  following  loop,  a 
single  execution  of  which  is  called  a  round* 


Do  forever 
begin 

[1] .  Set  for  each  resource  p(i)  requested  by  user  j. 

[2] .  Poll  for  cv  steps  to  see  which  resources  have  been  awarded  to 

user  j.  User  j  considers  the  resource  p(i)  awarded  only  if 
p(i)  has  been  both  aJlocated  (Fj^j  =  1)  and  not  yet  warned  (L^  .  «  0) . 


-IS¬ 


IS]  •  If  all  resources  requested  by  j  are  awarded  use  them  for 

y«v  steps  (M  is  a  constant,  controlled  by  the  implementation}* 

end 

A  phase  of  a  grant  process: 


Read 

priorities  t  Select 
cv  '  cv 


t  j  cv  ^ 

award  start 

resource  warning 


Sleep 

for  random 

_ I  interval  w 

2cv  t  • 
remove 

resource 


Figure  1 


A  round  of  a  requesting  process: 


ctsk.  loi.  X 

by  Poll  for 

+ _ flags _ i  resources  awarded  ^ 


If  all  awarded, 
use  them  i 


cv 


cv 


Figure  2 


4.2  Analysis 

Note  that  in  the  synchronous  case  assvuned  here,  the  time  is  essentially 
the  processes  steps.  The  power  of  the  adversary  is  thus  restricted  to  only  a 
possibly  malicious  initial  relative  shift  of  the  program  counters  of  the 
various  processes. 


LEMMA  4.1.  It  is  impossible  for  the  user  j  to  conclude  that  it  has 
got  all  resources  and  actually  some  of  the  resources  to  have  been  removed. 


Proof,  Since  the  polling  time  of  j  lasts  only  cv  steps,  by  the  time 
he  concludes  that  the  last  resource  is  allocated  to  him,  the  first  allocated 
resource  can  at  most  be  in  the  middle  of  the  warning  period  (and  hence  not 
removed  yet) . 

Note:  The  above  lemma  puts  a  limit  on  y.  It  must  be 

y  <  cv  -  1 

In  the  sequel  we  consider  priorities  -  1 

LEMMA  4.2.  The  probability  that  user  j  will  get  a  particular  resource 
in  its  current  round  is  >  1/lOv. 

Proof.  This  probability  is  equal  to 

Prob{flag  of  user  j  will  be  seen  by  the  resource  allocator 
in  the  current  round} 

•  Prob{j  will  be  selected  given  its  flag  was  seen} 

^11  a 

Note;  The  first  probability  is  >  1/10  due  to  the  random  waits 
incurred  by  the  resource  allocators.  These  waits  counteract  the  adverse 
relative  shifts* 

LEMMA  4.3.  The  probability  that  user  j  will  get  a  particular  resource 
in  its  current  round  is  <  1/v  for  the  worst  case  oracles m 

Proof.  Consider  oracles  which  put  maximum  contention  in  the  system. 
LEMMA  4.4.  The  probability  that  user  j  will  get  all  his  resources  in 

Ic  Ic 

the  acme  romd  ia '  >  l/(l0v)  and  is  <  1/v  . 
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Proof.  By  the  fact  that  granting  processes  sleep  for  random  intervals 
and  hence  their  relative  positions  in  the  algorithm  are  statistically 
independent  (and  liemmas  4.1,  4.3).  a 

Let  u  ==  #  rounds  required  for  user  i  to  succeed  in  being  granted  all 
its  k  resources  in  one  round.  Then 


\  (lOv)^  /  (v)^ 


implying 


mean(u)  <  (lOv)^  . 


If  u(e)  is  the  least  number  such  that  prob{u>u(e)}  <  C  then 


loo  / — — r-  \  -  loo  -V 

A, 


u(e)  = 


\(10v)'^/  V 

\  aovrl 


log  /  1 


=  k(lOv)^ 


for  large  v 


'  olkv"  109(1))  . 


Since  each  round  of  i  takes  <  3cv  steps#  we  have 


Prob{Yj^  ^  ^  3cv  u(e)}  >  1  -£ 


implying 


and 


^  IT . . 
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Note  that  the  RGS  implementation  by  flags  is  more  efficient  than  the  RGS 
implementation  by  an  underlying  DCS  system. 

4.3  Asynchronous  Case  with  Tame  Processes 

The  algorithms  and  the  analysis  in  this  case  are  exactly  the  same  with 

the  synchronous* case,  with  one  change:  The  constant  c  must  be  replaced  by 

c*  =  in  order  to  guarantee  that  cW  steps  of  a  process  in^ly  at 

least  cv  steps  of  any  other  process  and  at  most  c’Y  v  steps.  We  again 

max 

will  get 

Note  that  these  results  are  slightly  better  than  those  based  on  a  handshake 
communication  system,  since  there  is  no  uncertainty  about  flag  communication 
in  each  round.  However,  when  processes  are  not  tame,  the  oorTeotness  of  the 
inclement at ion  by  flags  may  be  violated,  while  the  correctness  of  the 
implementation  by  an  underlying  DCS  will  be  preserved  (because  of  the  hand¬ 
shake  communication  which  accompanies  allocation  or  deallocation  of  a 
resource)  given  that  the  correctness  of  the  underlying  DCS  is  not  violated 
when  processes  are  not  tame. 
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APPENDIX  I 

Distributed  (Handshake)  Communication  Systems  (DCS) 

Suppose  that  each  process  has  a  special  resource  called  channel  which 
can  be  in  one  of  two  states  open,  closed.  A  handshake  of  two  processes 
i,  j  in  time  t  is  a  combination  of  processes  states  at  time  t  so  that 
both  channels  of  i  and  j  are  open  at  the  same  time. 

We  require  that  successful  direct  communication  requires  a  handshake  of 
at  least  1  step  overlap  of  both  processes  and  that  the  handshake  relation 
should  be  a  matching.  At  any  instant  t  no  process  is  allowed  to  be  hand¬ 
shaking  with  more  than  one  other  process.  During  the  one  step  overlap,  a 
message  can  be  transmitted  from  one  process  to  the  other.  The  problem  is 
usual 3 V  to  svnchronize  nrocesses  (via  a  distributed  scheduler)  so  that  t'ev 
can  handshake  at  their  will,  given  that  the  means  of  synchronization  ic  some 
low  level  construct  (a  message  system,  buffered  communication,  shared 
variables  or  flags)  which  does  not  guarantee  the  handshake  property  if  used 
in  an  unsophisticated  way.  A  distributed  scheduler  is  called  veal  time  if  it 
has  the  property  that  if  two  processes  i,j  are  willing  to  handshake 
mutually  for  at  least  a  constant  time  interval,  then  they  will  actually 
achieve  successful  direct  communication  during  that  time  interval  with 
arbitrarily  small  probability  of  error. 

Formally,  let  T(e)  be  the  smallest  real  number  such  that  if  two 
processes  i,j  are  mutually  willing  to  handshake  for  at  least  T(e)  time, 
then  they  will  actually  succeed  in  1  step  overlap  of  open  channels  during  that 
time,  with  probability  ^  1-c.  T(e)  is  called  the  G-crror  response  of  the 
handshake  algorithm.  The  mean  response,  T  of  a  handshake  algorithm  is  the 


-22- 


maximum  (over  all  adverse  speed  schedules  of  tame  processes  and  overall  adverse 
communication  requests  subject  to  restrictions  stated  in  the  introduction)  of  the 
mean  time  needed  for  two  processes  to  handshake,  from  the  time  instant  they 
start  to  be  mutually  willing.  A  real  time  probabilistic  scheduler  has  T(e) 
depending  only  on  v  and  not  on  any  other  global  measure  of  the  communications 
graph.  (v  is  a  fixed  upper  bound  on  the  out-valence  of  the  dynamic  communication 
willingness  digraph  at  any  time  instant  t) .  We  also  require  T(e)  to  increase 
at  most  linearly  with  1/e.  Note  that  such  a  scheduler  has  T  also  depending 
only  on  v. 

The  handshake  problem  has  been  given  some  attention  in  literature 
[Schwartz,  79],  [Francez,  Rodeh  80],  [Francez,  81],  [Reif,  Spirakis  81], 

[Reif,  Spirakis  82]. 

For  Section  3  we  require  a  Distributed  Cormunioation  System  (DCS)  as 
defined  above  with  a  distributed  real  time  probabilistic  scheduler.  We  also 
require  the  DCS  to  have  the  following  property: 

If  a  process  i  is  willing  to  commxinicate  with  k^v  processes  for  at 
least  time  ^T(e)  and  if  they  are  also  willing  to  (handshake)  communicate 
with  i  during  that  interval,  then  the  probability  that  i  will  be  able  to 
communicate  with  all  of  them  (in  some  order)  within  T(e),  is  ^  (1-8)  . 

Such  a  real  time  DCS  was  implemented  in  [Reif,  Spirakis  81]  with 

T(e)  =  O(v^log(l/e)) 

and 

T  =  O(v^) 


